Description:

Introduces a new component, DefaultAlertButton, in the react module. It intends to be used by consuming MFEs in the Alert component's actions prop to ensure that Alert's CTAs can be reasonably configured to rely on a different default Button variant than is used in the upstream MFE code. For example, @edx/elm-theme calls for

However, this approach on its own, does not adequately address how the Paragon docs site itself would adhere to a change in the default Button variant used with Alert when previewing @edx/elm-theme.

To ensure the overridden alert button variant is applied consistently across all MFEs for a given instance, it may be recommended that operators define a common env.config (e.g., env.config.common.js) that is consumed by all MFE-specific env.config files so that MFEs don't need to duplicate the same style overrides in multiple places.

The idea here would be that openedx MFEs that supply actions to the Alert component should begin using DefaultAlertButton from @edx/frontend-platform/react instead so the configured button variant override is applied without any additional effort within the MFE. It should be as simple as replacing <Button> with <DefaultAlertButton> in the appropriate places.

See more details from the Paragon Working Group meeting on 4/2 here.

Next steps:

• Share and refine this proposed approach with 2U/edX.org's internal fedx meeting based on any early feedback.
• Draft an ADR to further document the rationale for this approach and adoption strategy throughout openedx.
  • Formalize the expected config structure within env.config for such style overrides, considering future use cases beyond the immediate Alert.
  • Get PR out of draft and into code review.

Merge checklist:

• Consider running your code modifications in the included example app within frontend-platform. This can be done by running npm start and opening http://localhost:8080.
• Consider testing your code modifications in another local micro-frontend using local aliases configured via the module.config.js file in frontend-build.
• Verify your commit title/body conforms to the conventional commits format (e.g., fix, feat) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.

Post merge:

• After the build finishes for the merged commit, verify the new release has been pushed to NPM.